<!DOCTYPE html>
<html lang="en">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Anonymous read-only access to the GCC project Git source repository." />
<meta name="keywords" content="Git, version control, GCC, source, public, repository" />
<title>GCC: Anonymous read-only Git access</title>
<link rel="stylesheet" type="text/css" href="https://gcc.gnu.org/gcc.css" />
</head>

<!-- GCC maintainers, please do not hesitate to update/contribute entries
     concerning branches you maintain!  2005-08-29, Gerald.
-->

<body>
<h1>GCC: Anonymous read-only Git access</h1>

<p>Our Git source repository is available read-only to the public at
large.  That way you can pick up any version (including releases) of
GCC that is in our repository.</p>

<p>In addition you
can <a href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git">browse our
Git history online</a>.</p>

<p>(Our <a href="about.html#git">web pages are managed via Git in a
separate repository</a>.)</p>


<h2>Using the Git repository</h2>

<p>Assuming you have
<a href="https://git-scm.com/">Git</a> installed, you can
check out the GCC sources using the following command:</p>

<blockquote><p>
<code>git clone git://gcc.gnu.org/git/gcc.git SomeLocalDir</code>
</p></blockquote>

<p>If you are behind a firewall that does not allow the git protocol
through, you can replace <code>git://</code> with <code>https://</code>.

<p>If there is another local repository accessible you can avoid
re-downloading everything by using <code>--reference</code>, e.g.</p>

<blockquote><code>git clone --reference original-gcc --dissociate ssh://gcc.gnu.org/git/gcc.git new-gcc</code></blockquote>

<p>But if you own this other copy, you probably want to use
separate <a href="#worktrees">worktrees</a> instead of multiple clones.

<!-- Comment out till savannah gets back to us (see above)
<p>In case of problems with the repository at savannah.gnu.org please
contact savannah-hackers@gnu.org.</p> -->


<h3 id="generated_files">Generated files</h3>

<p>Our source tree contains a number of files that are generated
from other source files by build tools such as Bison, Autoconf, and
Gperf.  Bison is now required when using Git to access our sources,
but all other generated files are included in the source tree so that
GCC can be built without these build tools. The Git checkout and
update operations do not insure that the timestamps of generated files
are later than those of the files they are generated from.  The script
<code>contrib/gcc_update</code> updates the timestamps for all these
generated files.  See the comments in that script for instructions on
running it.</p>

<p>GCC's build system (in particular Make) uses file timestamps to
determine if a generated file needs to be updated by running a particular
build tool.  Because of this, GCC's build system may believe that
a generated file needs regenerating even though its source has not
changed, and require a particular build tool to rebuild that generated
file.  If the appropriate build tool is installed on your system, then
this will not be a problem.  If you do not intend to make changes to
the source, you can avoid installing these build tools by running
<code>contrib/gcc_update</code>.</p>

<p>There has been some discussion of removing these generated files
from GCC's Git source tree (there is no discussion of removing them
from the released source tarballs).  If that happens then
building GCC from the Git source tree would require installing
the above mentioned build tools.  Installing these build tools is not
particularly difficult, but can be time consuming especially if you
only occasionally install GCC on a particular system.</p>

<p>The build tools that GCC uses are all available from the GNU
Project (see <a href="https://www.gnu.org">https://www.gnu.org</a>),
are often already available on many systems, and can often be found
already built for some systems.  A partial list of these build tools
is: Autoconf, Bison, Xgettext, Automake, and Gperf.</p>

<h3>Conflicts when using <code>git pull</code></h3>

<p>It is not uncommon to get Git conflict messages for some generated files
when updating your local sources from the Git repository.  Typically such
conflicts occur with autoconf generated files.  Such an error is of
the form:</p>

<blockquote><pre>
error: Your local changes to the following files would be overwritten by merge:
        gcc/configure
Please commit your changes or stash them before you merge.
Aborting
</pre></blockquote>

<p>As long as you haven't been making modifications to the generated files
or the generator files, it is safe to revert the local differences
using <code>git checkout</code> on the affected files, then run
<code>git pull</code> again.</p>

<p>If you have changes you want to keep that result in such an error,
there are a few options.  You can keep those changes on a local branch
rather than on a branch tracking upstream sources.  If you wish to
keep those changes uncommitted, do <code>git stash</code>
before <code>git pull</code> and <code>git stash pop</code>
after <code>git pull</code>.  If you commit them directly to your
local upstream-tracking branch, you may prefer to use <code>git pull
--rebase</code> instead of plain <code>git pull</code>.</p>


<h2 id="tags">Branches and Tags</h2>

<p>A branch called <em>branchname</em> can be checked out with the
following command:</p>

<blockquote><p>
<code>git checkout <em>branchname</em></code>
</p></blockquote>

<p>(The release branch of the GCC <em>SERIES</em> release series
is named <code>releases/gcc-<em>SERIES</em></code>.)</p>

<p>Similarly a tag called <em>tagname</em> can be checked out with the
following command:</p>

<blockquote><p>
<code>git checkout <em>tagname</em></code>
</p></blockquote>

<p>(The Git tag for GCC <i>X</i>.<i>Y</i>.<i>Z</i> is of the form
<code>releases/gcc-<em>X</em>.<em>Y</em>.<em>Z</em></code>.  Under the
release numbering scheme used for GCC 5 and later release
series, <em>Y</em> is always nonzero and <em>Z</em> is always zero for
a release, with other version numbers being used for development
versions.)</p>

<p>The following are some representative examples:</p>

<ul>
  <li>releases/gcc-10 (a branch)</li>
  <li>releases/gcc-9 (a branch)</li>
  <li>releases/gcc-9.3.0 (a tag)</li>
  <li>releases/gcc-4.9 (a branch)</li>
  <li>releases/gcc-4.9.0 (a tag)</li>
</ul>

<p>To get a list of available branches, after checking out any branch,
use the command:</p>
<blockquote>
<p>
<code>git branch -a</code>
</p>
</blockquote>

<p>Similarly, to list tags:</p>
<blockquote>
<p>
<code>git tag -l</code>
</p>
</blockquote>

<p>To view logs for a branch only up to the point at which it was
created, use the command <code>git log origin/<em>branchname</em>
^origin/<em>parentbranchname</em></code>; for example:

<blockquote>
<p>
<code>git log origin/releases/gcc-9 ^origin/master</code>
</p>
</blockquote>

<h3 id="worktrees">Worktrees</h3>

<p>Git allows you to share the git object repository between multiple working
directories, each tracking a different branch.  For instance, to create a
worktree for a release branch, do</p>

<blockquote><pre>
git worktree add ../gcc-9 releases/gcc-9
</pre></blockquote>

To create a worktree for a new project branch based on master, do

<blockquote><pre>
git worktree add -b <em>project</em> ../project master
</pre></blockquote>

<h3 id="repolayout">Repository Layout</h3>

<p>By default, a <code>git clone</code> operation will only fetch the
main development, release branches and their associated tags from the
server.  This will be sufficient for most users, but a number of
additional branches can also be fetched if necessary.</p>

<p>The following areas exist on the server:</p>
<ul>
  <li><i>refs/heads/master</i> - The active development version of the
    compiler.</li>
  <li><i>refs/heads/releases/*</i> - Release branches.</li>
  <li><i>refs/heads/devel/*</i> - topic-specific development branches
    - see <a href="#devbranches">Active Development Branches</a>.
    Branches and tags in this space may be moved to refs/dead once active
    development is completed or abandoned.</li>
  <li><i>refs/tags/*</i> - tags for all of the above branches.</li>
  <li><i>refs/vendors/*/{heads,tags}/*</i> - vendor-specific branches and
    tags.  These are owned and maintained by the respective
    vendor, but made available publicly.  Non-fast-forward pushes
    are permitted on these branches.</li>
  <li><i>refs/users/*/{heads,tags}/*</i> - personal developer branches and
    tags.  These are owned and maintained by the individual developer.
    Non-fast-forward pushes are permitted on these branches.</li>
  <li><i>refs/dead/heads/*</i> - completed or abandoned development
    branches.</li>
  <li><i>refs/meta/config</i> - local configuration data for the
    commit hooks on the server.</li>
  <li><i>refs/deleted/*/{heads,tags}/*</i> - old branches and tags
    from the SVN repository that were deleted before the conversion to
    git.</li>
  <li><i>refs/git-svn-old/*</i> - various branches and tags from the
    git-svn pre-conversion git mirror.</li>
  <li><i>refs/git-old/*</i> - various branches and tags from the
    git-svn pre-conversion git mirror that were local to that git
    repository.</li>
</ul>

<p>You can download any of the additional branches by adding a suitable
fetch specification to your local copy of the git repostiory.  For
example, if your remote is called 'origin' (the default with git
clone) you can add the 'dead' development branches by running:</p>

<blockquote><pre>
    git config --add remote.origin.fetch "+refs/dead/heads/*:refs/remotes/origin/dead/*"
    git config --add remote.origin.fetch "+refs/dead/tags/*:refs/tags/dead/*"
    git fetch origin
</pre></blockquote>

<p>which will place the dead branches in <code>remotes/origin/dead</code>
  and the tags in <code>tags/dead</code>.</p>

<p>You can use <code>git ls-remote</code> to get a complete list of
refs that the server holds.</p>

<h3 id="devbranches">Active Development Branches</h3>

<ul>
<li><a href="#general">General</a></li>
<li><a href="#arch">Architecture</a></li>
<li><a href="#target">Target</a></li>
<li><a href="#lang">Language</a></li>
<li><a href="#distrobranches">Distribution</a></li>
<li><a href="#merged">Merged</a></li>
<li><a href="#olddevbranches">Inactive</a></li>
	  
</ul>
      
<h4 id="general">General Infrastructure</h4>

<p>Active development branches have names starting <code>devel/</code>
in Git.</p>

<dl>

  <dt>ira-select</dt>
  <dd>This branch is for work on a new algorithm of calculations of
  pseudo register classes. The new algorithm is based on choosing an
  insn alternative first and then calculation of pseudo reg class
  costs knowing the alternative.  The branch is maintained by Vladimir
  Makarov <a href="mailto:vmakarov@redhat.com">vmakarov@redhat.com</a>.
  </dd>

  <dt><a href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/heads/devel/omp/gcc-12">devel/omp/gcc-12</a></dt>
  <dd>This branch is for collaborative development of
  <a href="https://gcc.gnu.org/wiki/OpenACC">OpenACC</a> and
  <a href="https://gcc.gnu.org/wiki/openmp">OpenMP</a> support and related
  functionality, such
  as <a href="https://gcc.gnu.org/wiki/Offloading">offloading</a> support (OMP:
  offloading and multi processing).
  The branch is based on releases/gcc-12.
  Please send patch emails with a short-hand <code>[og12]</code> tag in the
  subject line, and use <code>ChangeLog.omp</code> files.</dd>

  <dt>unified-autovect</dt>
  <dd>This branch is for work on improving effectiveness and generality of GCC's
  autovectorization by performing target-aware reordering instruction selection
  using unified representation. This branch is maintained by Sameera Deshpande
  &lt;<a href="mailto:sameera.deshpande@imgtec.com">sameera.deshpande@imgtec.com</a>&gt;.</dd>

</dl>

<h4 id="arch">Architecture-specific</h4>

<dl>
  <dt>power-ieee128</dt>
  <dd>This branch is for community development of IEEE quad precision floating
      point for Power ("ieee128"), replacing the "double double" aka "ibm128"
      implementation we had for long double.  The current focus is on Fortran
      support.</dd>
</dl>

<h4 id="target">Target-specific</h4>

<p>No active branches</p>
<!--
<dl>
</dl>
-->

<h4 id="lang">Language-specific</h4>

<dl>
  <dt>c++-contracts</dt>
  <dd>This is the sandbox for renewed work on <em>contracts for C++</em>, that
      didn't make it into C++20.  Most of the implementation was contributed by
      Lock3 Software.  It is currently maintained
      by <a href="mailto:jason@gcc.gnu.org">Jason Merrill</a>.</dd>

  <dt>gccgo</dt>
  <dd>This branch is for the Go front end to GCC.  For more information
    about the Go programming language,
    see <a href="https://go.dev/">go.dev</a>.  The
    branch is maintained by Ian Lance Taylor.  Patches should be
    marked with the tag [gccgo] in the Subject line.
  </dd>

  <dt>modula-2</dt>
  <dd>This branch is for the
    <a href="http://www.nongnu.org/gm2/homepage.html">GNU Modula-2</a>
    front end to GCC prior to its integration with the mainline.  The
    branch will be regularly rebased against the mainline.  It is
    maintained by
    <a href="mailto:gaius.mulley@southwales.ac.uk">Gaius Mulley</a>.
    Patches should be
    prefixed with <code>[modula-2]</code> in the subject line.</dd>

  <dt>m2link</dt>
  <dd>This is a short term branch for the
    <a href="http://www.nongnu.org/gm2/homepage.html">GNU Modula-2</a>
    front end to GCC prior to its integration with the mainline.
    It contains the new scaffold and driver development.  The contents
    of this branch will be folded back onto the <code>modula-2</code>
    branch once a significant number of regression tests pass.  It is
    maintained by
    <a href="mailto:gaius.mulley@southwales.ac.uk">Gaius Mulley</a>.
    Patches should be
    prefixed with <code>[m2link]</code> in the subject line.</dd>

  <dt>coarray_native</dt>
  <dd>This branch is for implementation of a shared memory
    implementation of Fortran coarrays.  It is maintained by
    <a href="mailto:koenigni@gcc.gnu.org">Nicolas K&ouml;nig</a>.</dd>
    
  <dt><a href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master">devel/rust/master</a></dt>
  <dd>
    This branch is for development of
    <a href="https://gcc.gnu.org/wiki/RustFrontEnd">Rust programming language
      support in GCC</a>.
  </dd>
</dl>

<h3 id="distrobranches">Distribution Branches</h3>

<p>These branches are maintained by organizations distributing GCC.
No changes should be made to those branches without the explicit
permission of the distributing organization.  Such branches are
located in the Git repository
under <code>refs/vendors/<em>vendor</em>/heads/</code>, which is not
fetched by default; the <code>heads/</code> is omitted from the names
given below.</p>

<dl>
  <dt>apple/local-200502-branch</dt>
  <dd>This branch is for various improvements in use at Apple and to
  coordinate work with others.  This branch is maintained by the folks
  at Apple.  Previous branch was apple-ppc-branch.</dd>

  <dt>ARM/embedded-<em>x_y</em>-branch</dt>
  <dd>These branches provide bug-fixes, minor enhancements and stability
  fixes for GCC <em>x.y</em> branches when used with ARM's embedded cores,
  such as the Cortex-R and Cortex-M processors.  Most patches will be
  limited ARM specific or common back-ports from trunk, unlike the current
  release branches.  Very occasionally these branches will hold patches
  that are waiting for trunk acceptance.  Patches for these branches should
  be marked with the tag <code>[arm-embedded]</code> in the subject line.
  This family of branches is maintained by personnel from ARM.</dd>

  <dt>google/integration</dt>
  <dd>This branch contains some minimal patches that are likely not
  useful anywhere outside of Google's build environment. These are
  typically configuration patches.  The branch is maintained by
  Diego Novillo <a href="mailto:dnovillo@google.com">dnovillo@google.com</a>.
  </dd>

  <dt>google/main</dt>
  <dd>This branch contains Google local patches that are staged to be
  contributed to trunk.  Some of these patches are either in the
  process of being reviewed, or have not yet been proposed.  The
  intent of this branch is to serve as a staging platform to allow
  collaboration with external developers.  Patches in this branch are
  only expected to remain here until they are reviewed and accepted in
  trunk. This branch is maintained by
  Diego Novillo <a href="mailto:dnovillo@google.com">dnovillo@google.com</a>.
  </dd>

  <dt>google/gcc-<em>x_y</em></dt>
  <dd>Google compilers based on GCC <em>x.y</em> releases.  This family of
  branches is maintained by Diego Novillo
  <a href="mailto:dnovillo@google.com">dnovillo@google.com</a>.
  </dd>

  <dt>google/gcc-<em>x_y[_z]</em>-mobile</dt>
  <dd>Google compilers based on GCC <em>x.y.z</em> releases.  These are used
  to build Android and ChromeOS. This family of branches is maintained by
  Ahmad Sharif <a href="mailto:asharif@google.com">asharif@google.com</a>,
  Han Shen <a href="mailto:shenhan@google.com">shenhan@google.com</a>,
  and Jing Yu <a href="mailto:jingyu@google.com">jingyu@google.com</a>.
  </dd>

  <dt>google/gcc-<em>x_y[_z]</em>-mobile-vtable-security</dt>
  <dt>google/gcc-<em>x_y[_z]</em>-mobile-vtable-verification</dt>
  <dd>Google compilers based on GCC <em>x.y.z</em> releases.  These are used
  to build Android and ChromeOS. These branches are for work on function
  pointer and vtable security.  They are maintained by Caroline Tice
  <a href="mailto:cmtice@google.com">cmtice@google.com</a>.
  </dd>

  <dt>ibm/gcc-<em>x</em>-branch</dt>
  <dd>Branches that track the GCC branches and are used to create the
  IBM Advance Toolchain releases.  This family of branches is maintained by
  personnel from IBM.</dd>

  <dt>linaro/gcc-<em>x_y</em>-branch</dt>
  <dd>Linaro compilers based on GCC <em>x.y</em> releases.  These branches
  only accept backports of patches which have been accepted to trunk.  This
  family of branches is maintained by personnel from Linaro.</dd>

  <dt>redhat/gcc-3_2-branch</dt>
  <dd>Red Hat GNU/Linux compilers based on GCC 3.2.x.</dd>

  <dt>redhat/gcc-3_4-branch</dt>
  <dd>Red Hat GNU/Linux compilers based on GCC 3.4.x.</dd>

  <dt>redhat/gcc-4_0-branch</dt>
  <dd>Red Hat GNU/Linux compilers based on GCC 4.0.x.</dd>

  <dt>redhat/gcc-4_1-branch</dt>
  <dd>Red Hat GNU/Linux compilers based on GCC 4.1.x.</dd>

  <dt>redhat/gcc-4_3-branch</dt>
  <dd>Red Hat GNU/Linux compilers based on GCC 4.3.x.</dd>

  <dt>suse/gcc-4_1-branch</dt>
  <dd>SUSE GNU/Linux compilers based on GCC 4.1.x.</dd>

  <dt>suse/gcc-4_2-branch</dt>
  <dd>SUSE GNU/Linux compilers based on GCC 4.2.x.</dd>

  <dt>ubuntu/gcc-4_2-branch</dt>
  <dd>This branch follows the gcc-4_2-branch, except for gcc/java, boehm-gc,
  libffi, libjava and zlib, which are backported from the trunk (and from
  gcc-4_3-branch, once created). The branch is used as the base for the
  Debian and Ubuntu gcc-4.2 source package.</dd>

</dl>

<h3 id="merged">Merged Development Branches</h3>

<p>These branches have been merged to GCC mainline, and are thus
inactive.  Inactive branches are under <code>refs/dead/heads/</code>
in Git (except for ones under <code>refs/vendors/</code>).</p>

<dl>
  <dt><a href="https://gcc.gnu.org/git/?p=gcc-old.git;a=shortlog;h=refs/heads/aarch64/sve-acle-branch">aarch64/sve-acle-branch</a></dt>
  <dd>This <a href="https://gcc.gnu.org/wiki/GitMirror">Git-only branch</a> was
  used for collaborative development of the AArch64 SVE ACLE implementation.
  The branch is based off and merged with trunk.  Please send patches to
  gcc-patches with an <code>[SVE ACLE]</code> tag in the subject line.
  There's no need to use ChangeLogs; the ChangeLogs will instead be
  written when the work is ready to be merged into trunk.  The branch is
  maintained by Richard Sandiford.</dd>

  <dt>ARM/aarch64-branch</dt>
  <dd>This branch added support for the AArch64 architecture and tracked
    trunk until the port was merged into mainline.</dd>

  <dt>alias-improvements</dt>
  <dt>c-4_5-branch</dt>
  <dt>cfg-branch</dt>
  <dd>This branch was created to develop and test infrastructure
  for easier writing of new RTL based optimizations.  The branch
  was based on GCC pre-3.3 and has been partially merged into the
  mainline for GCC 3.4.  It is now closed, and work continues on
  the rtlopt-branch.</dd>

  <dt>cond-optab</dt>
  <dt>cp-parser-branch</dt>
  <dt>cp-parser-branch-2</dt>
  <dt>csl-*-branch</dt>
  <dt>csl/coldfire-4_1</dt>
  <dt>cxx0x-branch</dt>
  <dd>This branch was for the development of C++0x features, and all
  features developed on this branch have been merged to mainline. Future
  C++0x features will be developed against mainline.  This branch was
  deleted at revision 152320.</dd>
  <dt><a href="projects/cxx0x.html#lambdas">cxx0x-lambdas-branch</a></dt>
  <dd>This branch was for the development of lambda functions, a coming
  feature in C++0x.  It was merged into the trunk at revision 152318.</dd>

  <dt>dataflow-branch</dt>
  <dd>This branch has been merged into mainline on June 6, 2007
  as svn revision 125624.  It used to contain a replacement of back-end
  dataflow with df.c based dataflow. The branch was maintained
  by Daniel Berlin &lt;
  <a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>&gt;
  and Kenneth Zadeck &lt;<a href="mailto:zadeck@naturalbridge.com">
    zadeck@naturalbridge.com</a>&gt; </dd>


  <dt>dfa-branch</dt>
  <dt>dfp-branch </dt>
  <dt>edge-vector-branch </dt>
  <dt>fixed-point</dt>
  <dt>function-specific-branch</dt>
  <dd>This branch is for development of adding function specific options to
  GCC.  See the GCC
  <a href="https://gcc.gnu.org/wiki/FunctionSpecificOpt">wiki</a> for a more
  detailed project description.  Patches should be marked with the tag
  <code>[function-specific]</code> in the subject line.
  The branch has been merged into GCC 4.4.</dd>

  <dt>gcc-3_4-basic-improvements-branch</dt>
  <dt>gcc-3_4-e500-branch</dt>
  <dd>This branch was for stabilization of the powerpc-*spe
  architecture, and for adding support for the 8548 chip (e500 v2).  This
  branch was maintained by Aldy Hernandez.  All the e500 support was
  merged to mainline.</dd>

  <dt>gcj-abi-2-dev-branch</dt>
  <dt>gcj-eclipse-branch</dt>
  <dt><a href="https://gcc.gnu.org/wiki/tuples/">gimple-tuples-branch</a></dt>
  <dt>gomp-20050608-branch</dt>
  <dt>gomp-3_0-branch</dt>

  <dt>java-gui-20050128-branch</dt>
  <dd>This was a temporary branch for development of java GUI libraries
  (AWT and Swing) in the libjava directory.  It has been merged into
  mainline.</dd>

  <dt>killloop-branch</dt>
  <dd>The missing optimizations and optimization improvements necessary
  for removing the old loop optimizer were developed on this branch.
  Most of these changes were merged in 4.2.</dd>

  <dt><a href="projects/tree-ssa/lno.html">lno-branch</a></dt>
  <dd>A sub-branch of tree-ssa that aims at implementing a loop
  nest optimizer at the tree level.  Was largely merged into mainline,
  and is currently unmaintained.
  This work now continues on the autovect-branch.</dd>

  <dt><a href="https://gcc.gnu.org/wiki/MemRef">mem-ref2</a></dt>
  <dt>mips-3_4-rewrite-branch</dt>
  <dt>named-addr-spaces-branch</dt>
  <dd>This branch was the development branch to add named address space support
  for architectures that have multiple address spaces.  The CELL/spu architecture
  adds an <code>__ea</code> keyword to describe extended memory in the host chip
  address space instead of the local CELL/spu address space.  The branch was
  created by Ben Elliston, modified by Michael Meissner and eventually maintained by
  <a href="mailto:Ulrich.Weigand@de.ibm.com">Ulrich Weigand</a>.  All changes from
  this branch were merged into mainline.</dd>

  <dt>microblaze</dt>
  <dd>This branch contained support for updating the Xilinx MicroBlaze
  architecture to GCC 4.1.2.
  It was created by Michael Eager
  &lt;<a href="mailto:eager@eagercon.com">eager@eagercon.com</a>&gt;.
  All changes have been merged into mainline.</dd>

  <dt>pch-branch</dt>
  <dt><a href="projects/tree-ssa/">tree-ssa-20020619-branch</a></dt>
  <dt><a href="https://gcc.gnu.org/wiki/Var_Tracking_Assignments">var-tracking-assignments*-branch</a></dt>

  <dt>predcom</dt>
  <dd>This branch aimed to implement predictive commoning optimization
  and to introduce the changes to the representation of Fortran arrays,
  alias analysis and dependency analysis to make it useful for
  the common applications (e.g., mgrid).  The branch was merged
  in 4.3.</dd>

  <dt>split</dt>
  <dd>For development of stack splitting, as described
  on <a href="https://gcc.gnu.org/wiki/SplitStacks">the GCC wiki</a>.
  This branch was maintained by Ian Lance Taylor.  All changes were
  merged into mainline.</dd>

  <dt>tr29124</dt>
  <dd>This branch is for development of TR29124 Special math Functions,
    for the C++ runtime library
    See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3060.pdf">
    </a>.  It is maintained by Ed Smith-Rowland
    &lt;<a href="mailto:3dw4rd@verizon.net">3dw4rd@verizon.net</a>&gt;.</dd>

  <dt>tree-cleanup-branch</dt>
  <dd>This branch contained improvements and reorganization to the
  tree optimizers that were not ready in time for GCC 4.0.  The
  goal was to cleanup the tree optimizers and improve the sequencing
  of the passes.  It has now been merged into mainline for the
  4.1 release.</dd>

</dl>

<h3 id="olddevbranches">Inactive Development Branches</h3>

<p>These branches are inactive and contain work that might not been
merged.</p>
	
<dl>
  <dt>arc-20081210-branch</dt>
  <dd>The goal of this branch is to make the port to the ARCompact
  architecture available.  This branch is maintained by Joern Rennecke
  during spring 2009, and is expected to be unmaintained thereafter.</dd>

  <dt>ARM/hard_vfp_4_4_branch</dt>
  <dd>This branch contains support for the hard-VFP variant of the AAPCS calling
  standard and tracked gcc-4.4 development.  This branch was maintained by 
  Richard Earnshaw.</dd>

  <dt>addressing-modes</dt>
  <dd>This branch aimed to clean up the way base and index registers are
  handled by target headers.  In particular, the strict and non-strict
  meaning of these registers are unified and a common API is presented to
  implementations of the target macros.  Obsolete target macros will also
  be removed.  The branch was maintained by Paolo Bonzini.  It is no
  longer maintained.</dd>

  <dt>alias-export</dt>
  <dd>This branch contains the alias export and data dependency export patch.
  It is used to experiment with the propagation process.  This branch is maintained
  by Andrey Belevantsev <a href="mailto:abel@ispras.ru">abel@ispras.ru</a>.</dd>

  <dt id="annotalysis">annotalysis</dt>
  <dd>This branch contains the implementation of thread safety annotations
  and analysis (<a href="https://gcc.gnu.org/wiki/ThreadSafetyAnnotation">https://gcc.gnu.org/wiki/ThreadSafetyAnnotation</a>).
  The branch was maintained by
  <a href="mailto:delesley@google.com">Delesley Hutchins</a>.</dd>

  <dt>apple-ppc-branch</dt>
  <dd>This branch was for various improvements in use at Apple and to
  coordinate work with others.  This branch was maintained by the folks
  at Apple.  It has been superseded by apple-local-200502-branch.</dd>

  <dt><a href="projects/ast-optimizer.html">ast-optimizer-branch</a></dt>
  <dd>The purpose of this branch was to improve GCC's tree based
  optimizations.  The patches of this branch have been moved to the
  tree-ssa-20020619-branch.</dd>

  <dt>autovect-branch</dt>
  <dd>This branch is the successor to the lno-branch.  The purpose of this
  branch is tree-level <a href="projects/tree-ssa/vectorization.html">
  autovectorization</a> work, and related work that the autovectorizer
  could use or benefit from (like data-dependence analysis,
  <a href="projects/tree-ssa/lno.html">loop nest optimizations</a>).</dd>

  <dt>avx512</dt>
  <dd>The goal of this branch is to implement Intel AVX-512 and SHA
  Programming Reference.
  The branch is maintained by Yukhin Kirill &lt;<a
  href="mailto:kirill.yukhin@intel.com">kirill.yukhin@intel.com</a>&gt;.
  Patches should be marked with the tag <code>[AVX512]</code> in the subject
  line.</dd>

  <dt>avx-512vlbwdq</dt>
  <dd>The goal of this branch is to implement the Intel AVX-512{VL,BW,DQ}
  Programming Reference.
  The branch is maintained by Yukhin Kirill &lt;<a
  href="mailto:kirill.yukhin@intel.com">kirill.yukhin@intel.com</a>&gt;.
  Patches should be marked with the tag <code>[AVX512]</code> in the subject
  line.</dd>

  <dt>avx2</dt>
  <dd>The goal of this branch is to implement AVX Programming Reference
  (June, 2011). The branch is maintained by
  H.J. Lu &lt;<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>&gt;
  and Yukhin Kirill &lt;<a href="mailto:kirill.yukhin@intel.com">kirill.yukhin@intel.com</a>&gt;.
  Patches should be marked with the tag <code>[AVX2]</code> in the subject
  line.</dd>

  <dt>bje-unsw-branch</dt>
  <dd>This branch was dedicated to some research work by Ben Elliston
    at the University of New South Wales (UNSW) on transformation
    phase ordering.  It will never merge with mainline, although a
    selection of patches may be submitted over time.  Deleted by
    revision 152653.</dd>

  <dt>boehms-gc</dt>
  <dd>The goal of this branch was to test Boehm's GC feasibility as the
  garbage collector for GCC proper.  This was a part of Google Summer
  of Code project, described in detail
  at <a href="https://gcc.gnu.org/wiki/Garbage_collection_tuning">https://gcc.gnu.org/wiki/Garbage_collection_tuning</a>.  The
  branch was maintained
  by <a href="mailto:laurynas.biveinis@gmail.com">Laurynas
  Biveinis</a>.</dd>

  <dt>cell-4_3-branch</dt>
  <dd>The goal of this branch is to add fixes and additional features required
  for the Cell/B.E. processor (both PPE and SPE) to GCC 4.3.x.  This branch
  is maintained by Ulrich Weigand.</dd>

  <dt>cell-4_4-branch</dt>
  <dd>The goal of this branch is to back-port from mainline fixes and additional
  features required for the Cell/B.E. SPE processor to GCC 4.4.x.  This branch
  is maintained by Ulrich Weigand.  The branch is merged from gcc-4_4-branch.</dd>

  <dt><a href="projects/cfo.html">cfo-branch</a></dt>
  <dd>The goal of this branch was to add a new extension for improving
  the code size optimization of GCC with code factoring methods (code
  motion and merging algorithms).  It is no longer maintained.</dd>

  <dt>cilkplus</dt>
  <dd>This branch was for the development of Cilk Plus language extension
  support on GCC and G++ compilers.  It was maintained by Balaji V. Iyer.
  </dd>

  <dt>compile-server-branch</dt>
  <dd>This branch was aimed at improving compile speed by caching work
  done between compilations.  The work saved is mainly related to header
  file processing.  This branch was maintained by Mike Stump and Per Bothner.
  Patches were marked with the tag <code>[cs]</code> in the subject
  line.</dd>

  <dt><a href="https://gcc.gnu.org/wiki/Condate">condate-branch</a></dt>
  <dd>The purpose of this branch is to develop a language for checking
  control flow graph properties.  The code of this branch has not been
  merged in trunk.</dd>

  <dt>cxx-conversion</dt>
  <dd>This branch hosts mini-projects that rewrite parts of the existing
  GCC code into C++.  Each conversion project will be proposed for
  trunk integration independently.  The branch is maintained by
  <a href="mailto:dnovillo@google.com">Diego Novillo</a>.  Patches
  sent to this branch and discussions related to it should be marked
  with the tag <code>[cxx-conversion]</code> in the subject line.  For
  details on working with this branch, see the
  <a href="https://gcc.gnu.org/wiki/cxx-conversion">C++ conversion</a>
  page.</dd>

  <dt><a href="https://gcc.gnu.org/wiki/Atomic/GCCMM">cxx-mem-model</a></dt>
  <dd>This branch is for the implementation of the C++ memory model.
  Patches for this branch should be marked <code>[cxx-mem-model]</code>
  in the subject line.  The branch is maintained by Aldy Hernandez.</dd>

  <dt><a href="projects/cxx-reflection/">cxx-reflection-branch</a></dt>
  <dd>Part of the work on providing support for compile time reflection
  in C++ was done in this branch.  This branch was maintained by Gabriel
  Dos Reis
  &lt;<a href="mailto:gdr@integrable-solutions.net">gdr@integrable-solutions.net</a>&gt;.
  It is no longer maintained.</dd>

  <dt><a href="projects/cxx0x.html#concepts">cxx0x-concepts-branch</a></dt>
  <dd>This branch contains the beginnings of a re-implementation of
    Concepts, a likely future feature of C++, using some of the code from
    the prototype implementation on conceptgcc-branch.  It is not currently
    maintained.</dd>

  <dt>cygwin-improvements</dt>
  <dd>This branch is intended as a development and proving grounds for
  fixes and enhancements specifically to the Cygwin port of the compiler,
  although some of these may touch slightly on MinGW targets as well.  It
  is maintained by Dave Korn &lt;<a href="mailto:dave.korn.cygwin@gmail.com"
  >dave.korn.cygwin@gmail.com</a>&gt; and open to contributions from any
  interested party; please tag patches with "[cygwin-improvements]" in the
  title line and post them to the GCC Patches list with a Cc: to that
  address.</dd>

  <dt><a href="https://gcc.gnu.org/wiki/AndrewMacLeod/debuglocus">debuglocus</a></dt>
  <dd>This branch is an experiment to see whether improved debug information 
  can be maintained throughout the compiler by associating a user decl with an 
  expression, statement, or insn.  The name comes from attempting to utilize
  the ever present source location (locus) field to carry the debug info.
  Further information can be found on the <a href="https://gcc.gnu.org/wiki/AndrewMacLeod/debuglocus">debuglocus</a> wiki page .</dd>

  <dt>dwarf4</dt>
  <dd>This branch is for support of DWARF-4 features.
  DWARF-4 is currently under development, so changes on this branch
  will remain experimental until Version 4 is officially finalized.</dd>

  <dt>faster-compiler-branch</dt>
  <dd>This was a temporary branch for compiler speedups for GCC 3.4.
  See <a href="https://gcc.gnu.org/ml/gcc/2002-08/msg00498.html">this
  thread</a> for discussion of possible work still to be done in this
  area.  The branch is unmaintained at present.</dd>

  <dt>fortran-caf</dt>
  <dd>This branch contained experimental changes to the Fortran front end for
    implementing the library calls for coarray communication.  It was
    maintained by Tobias Burnus
    &lt;<a href="mailto:burnus@gcc.gnu.org">burnus@gcc.gnu.org</a>&gt;.</dd>

  <dt>fortran-dev</dt>
  <dd>This branch was for disruptive changes to the Fortran front end,
    especially for OOP development and 
    the <a href="https://gcc.gnu.org/wiki/ArrayDescriptorUpdate">
    array descriptor update</a>.  It was maintained by Jerry DeLisle
    &lt;<a href="mailto:jvdelisle@gcc.gnu.org">jvdelisle@gcc.gnu.org</a>&gt;.</dd>

  <dt>fortran-exp</dt>
  <dd>This branch contained experimental changes to the Fortran front end, initially
    for array constructor refactoring using splay-tree and other areas of
    optimization.  It was maintained by Jerry DeLisle
    &lt;<a href="mailto:jvdelisle@gcc.gnu.org">jvdelisle@gcc.gnu.org</a>&gt;.</dd>

  <dt>gcc-3_3-e500-branch</dt>
  <dd>This branch was for backporting the PowerPC/E500 back end to GCC 3.3.
  See <a href="https://gcc.gnu.org/ml/gcc/2003-04/msg00733.html">this
  message</a> for details.</dd>

  <dt>gcc-4_4-plugins</dt>
  <dd>This branch is for backporting the plugin functionality into
  a 4.4-based release.  There will be no new code or functionality
  added to this branch.  It is maintained by Diego Novillo.
  Only patches backported from mainline are accepted.  They should
  be marked with the tag [4_4-plugins] in the Subject line.</dd>

  <dt>gcc-in-cxx</dt>
  <dd>This branch was for converting GCC to be written in C++.  The
  branch was maintained by Ian Lance Taylor.</dd>

  <dt>gcjx-branch</dt>
  <dd>This branch was used for development of gcjx, a rewrite of the
    front end for the Java programming language.  It has been superseded
    by gcj-eclipse-branch. </dd>

  <dt>gc-improv</dt>
  <dd>This branch is for the development of garbage collector
  improvements.  It is the successor to the boehm-gc branch, but
  without integration with Boehm's GC.  The branch is maintained
  by <a href="mailto:laurynas.biveinis@gmail.com">Laurynas
  Biveinis</a>.  Patches for this branch should be marked with the
  tag <code>[gc-improv]</code> in the subject line.</dd>

  <dt>gimple-front-end</dt>
  <dd>This branch implements a front end for GIMPLE.  It is maintained
  by <a href="mailto:dnovillo@google.com">Diego Novillo</a>.  Patches
  should be prefixed with <code>[gimplefe]</code> in the subject line.  See
  the <a href="https://gcc.gnu.org/wiki/GimpleFrontEnd">GIMPLE Front End</a>
  page for details.</dd>

  <dt><a href="https://gcc.gnu.org/wiki/Graphite">graphite-branch</a></dt>
  <dd>The purpose of this branch is to develop an infrastructure for loop
  transforms using the polyhedral model.</dd>

  <dt>gomp-01-branch</dt>
  <dt>gomp-branch</dt>
  <dd>These two branches were initial attempts to implement
  OpenMP support in GCC.  They were never properly maintained and
  have now been superseded by <code>gomp-20050608-branch</code>.</dd>

  <dt>gomp-4_0-branch</dt>
  <dd>This branch was based on gcc-6-branch, and was used to update
  the <a href="https://gcc.gnu.org/wiki/openmp">OpenMP support</a> to version
  4.0, including development
  of <a href="https://gcc.gnu.org/wiki/Offloading">offloading support</a> in
  GCC as well as support
  for <a href="https://gcc.gnu.org/wiki/OpenACC">OpenACC</a>.  These features
  got merged into trunk.  The branch was then used for on-going development
  of OpenACC support and related functionality, which subsequently moved to
  openacc-gcc-7-branch and then openacc-gcc-8-branch (both now also inactive,
  see below).</dd>

  <dt><a href="projects/gupc.html">gupc</a></dt>
  <dd>This branch implements support for UPC (Unified Parallel C).
  UPC extends the C programming language to provide support for
  high-performance, parallel systems with access to a single
  potentially large, global shared address space.
  Further information can be found on the
  <a href="https://github.com/Intrepid/GUPC">GNU UPC</a> page.</dd>

  <dt>openacc-gcc-7-branch</dt>
  <dt>openacc-gcc-8-branch</dt>
  <dt>openacc-gcc-9-branch</dt>
  <dd>These branches were used for development of
  <a href="https://gcc.gnu.org/wiki/OpenACC">OpenACC support</a> and related
  functionality, based on gcc-7-branch, gcc-8-branch, and gcc-9-branch
  respectively.</dd>

  <dt><a href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/heads/devel/omp/gcc-9">devel/omp/gcc-9</a></dt>
  <dt><a href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/heads/devel/omp/gcc-10">devel/omp/gcc-10</a></dt>
  <dt><a href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/heads/devel/omp/gcc-11">devel/omp/gcc-11</a></dt>
  <dd>These branches were used for collaborative development of
  <a href="https://gcc.gnu.org/wiki/OpenACC">OpenACC</a> and
  <a href="https://gcc.gnu.org/wiki/openmp">OpenMP</a> support and related
  functionality as the successors to openacc-gcc-9-branch after the move to
  Git.
  The branches were based on releases/gcc-9, releases/gcc-10 and
  releases/gcc-11 respectively.
  Development has now moved to the devel/omp/gcc-12 branch.</dd>

  <dt>hammer-3_3-branch</dt>
  <dd>The goal of this branch was to have a stable compiler based on GCC 3.3
  with improved performance for AMD's 64-bit Hammer CPUs. The branch was
  maintained by Jan Hubicka &lt;<a href="mailto:jh@suse.cz">jh@suse.cz</a>&gt;
  and Andreas Jaeger &lt;<a href="mailto:aj@suse.de">aj@suse.de</a>&gt;.
  Patches added on this branch might not be appropriate for the GCC 3.3
  branch due to our policies concerning release branches.  All patches
  were added to mainline GCC (for 3.4).</dd>

  <dt>ia64-fp-model-branch</dt>
  <dd>This branch was a development branch with the goal of
  implementing the improvements and features discussed at the <a href=
  "https://gcc.gnu.org/wiki/ia64_floating_point">ia64 floating point</a>
  page on the <a href="https://gcc.gnu.org/wiki/">GCC wiki</a>.  It was
  maintained by Zack Weinberg &lt;<a
  href="mailto:zack@codesourcery.com">zack@codesourcery.com</a>&gt;.
  It is no longer maintained.</dd>

  <dt>ia64-improvements</dt>
  <dd>The goal of this branch was to improve the performance of binaries
  generated with GCC on the Itanium processor.  Details can be found at the
  <a href="projects/ia64.html">IA-64 improvements</a> page.  This branch
  was maintained by Robert Kidd  &lt;<a
  href="mailto:rkidd@crhc.uiuc.edu">rkidd@crhc.uiuc.edu</a>&gt; and
  Diego Novillo.  It is no longer maintained.</dd>

  <dt>ibm/power7-tmp</dt>
  <dd>This branch was used to stage patches for Power7 (PowerPC ISA 2.06)
  from the development branch to the mainline.  The branch was maintained by
  Michael Meissner,
  <a href="mailto:meissner@linux.vnet.ibm.com">meissner@linux.vnet.ibm.com</a>.</dd>

  <dt>improved-aliasing-branch</dt>
  <dd>This branch contains improvements to the tree-based aliasing
  infrastructure.  The branch was maintained by Daniel Berlin &lt;<a
  href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>&gt; and
  Diego Novillo &lt;<a href="mailto:dnovillo@redhat.com">
    dnovillo@redhat.com</a>&gt;.  It is no longer maintained.</dd>

  <dt>ix86/avx</dt>
  <dd>The goal of this branch is to implement Intel AVX (Intel Advanced
  Vector Extensions).  The branch is maintained by
  H.J. Lu &lt;<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>&gt;.
  Patches should be marked with the tag <code>[AVX]</code> in the subject
  line.</dd>

  <dt>insn-select</dt>
  <dd>This branch aimed to implement in early instruction selection
  and register class selection pass, which runs before register allocation
  and subsumes the current <code>regclass</code> pass.  In particular
  the goal is to chose an alternative per instruction, usable as a base
  during register allocation, which ideally is not changed during reload
  if registers could be allocated.  This will not be possible in all cases,
  especially when addresses generated during spilling will be invalid on
  the target machine.  But we should be able to do away with fake register
  classes representing strict unions of other register classes.  The
  branch was maintained by Michael Matz.  It is no longer
  maintained.</dd>

  <dt>ix86/gcc-4_5-branch</dt>
  <dd>The goal of this branch is to backport support from trunk for
  newer ix86 processors from AMD and Intel. It will track
  4.5 branch with periodic merge from 4.5 branch.  The current
  maintainers are Sebastian Pop
  &lt;<a href="mailto:sebpop@gmail.com">sebpop@gmail.com</a>&gt;
  and H.J. Lu
  &lt;<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>&gt;.</dd>

  <dt>ix86/gcc-4_4-branch</dt>
  <dd>The goal of this branch is to add support for newer ix86 processors such
  as AMD's Shanghai and Intel's Atom to GCC 4.4.x.  The current maintainers
  are Dwarakanath Rajagopal &lt;<a href="mailto:dwarak.rajagopal@amd.com">dwarak.rajagopal@amd.com</a>&gt;
  and H.J. Lu &lt;<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>&gt;.</dd>

  <dt>ix86/gcc-4_3-branch</dt>
  <dd>The goal of this branch is to add support for newer ix86 processors such
  as AMD's Barcelona and Intel's Westmere to GCC 4.3.x.  The current maintainers
  are Dwarakanath Rajagopal &lt;<a href="mailto:dwarak.rajagopal@amd.com">dwarak.rajagopal@amd.com</a>&gt;
  and H.J. Lu &lt;<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>&gt;.</dd>

  <dt>ix86/gcc-4_2-branch</dt>
  <dd>The goal of this branch is to add support for newer ix86 processors such
  as AMD's Barcelona and Intel's Core 2 to GCC 4.2.x.  The current maintainers
  are Dwarakanath Rajagopal &lt;<a href="mailto:dwarak.rajagopal@amd.com">dwarak.rajagopal@amd.com</a>&gt;
  and H.J. Lu &lt;<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>&gt;.</dd>

  <dt>ix86/gcc-4_1-branch</dt>
  <dd>The goal of this branch is to add support for newer ix86 processors such
  as AMD's Barcelona and Intel's Core 2 to GCC 4.1.x.  The current maintainers
  are Dwarakanath Rajagopal &lt;<a href="mailto:dwarak.rajagopal@amd.com">dwarak.rajagopal@amd.com</a>&gt;
  and H.J. Lu &lt;<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>&gt;.</dd>

  <dt>java-gui-branch</dt>
  <dd>This was a temporary branch for development of java GUI libraries
  (AWT and Swing) in the libjava directory.  It has been superseded
  by java-gui-20050128-branch</dd>

  <dt>libada-gnattools-branch</dt>
  <dd>This is the spiritual successor to the libada branch.  This branch
  exists to solve
  <a href="https://gcc.gnu.org/PR5911">bug 5911</a>
  and others, by breaking out the Ada runtime into a libada directory and
  the Ada tools into a gnattools directory.  Work was devoted to
  cleaning up the configure and make machinery, and separating it as much
  as possible from the GCC build machinery.  Nathanael Nerode
  &lt;<a href="mailto:neroden@gcc.gnu.org">neroden@gcc.gnu.org</a>&gt;
  maintained this branch.  It is no longer maintained.</dd>

  <dt>libobjc-branch</dt>
  <dd>The branch is aimed to clean up libobjc and make it run on Darwin.
  Patches should be marked with the tag <code>[libobjc-branch]</code>
  in the subject line. Patches can be approved by Andrew Pinski
  &lt;<a href="mailto:pinskia@gcc.gnu.org">pinskia@gcc.gnu.org</a>&gt;
  or Nicola Pero
  &lt;<a href="mailto:n.pero@mi.flashnet.it">n.pero@mi.flashnet.it</a>&gt;.</dd>

  <dt>libstdcxx_so_7-branch</dt>
  <dd>This was a branch for experimental work on the C++ Runtime Library
  (libstdc++-v3) beyond the current version 6 library ABI. Paolo Carlini
  &lt;<a href="mailto:pcarlini@suse.de">pcarlini@suse.de</a>&gt;
  and Benjamin Kosnik
  &lt;<a href="mailto:bkoz@redhat.com">bkoz@redhat.com</a>&gt; were
  maintaining this branch.  It is no longer maintained.</dd>

  <dt>libstdcxx_so_7-2-branch</dt>
  <dd>This branch carries all the C++ Runtime Library (libstdc++-v3) patches
  that break its abi. It will be merged into the trunk as soon as the decision
  to move to abi version 7 will have been taken. It is maintained by
  <a href="mailto:frs.dumont@gmail.com">Fran&ccedil;ois Dumont</a> and the official
  libstdc++-v3 maintainers Paolo Carlini, Benjamin Kosnik and Jonathan Wakely.
  Patches will be marked with the tag <code>[so_7-2]</code> in the subject
  line.</dd>

  <dt>lra</dt>
  <dd>This branch contains the Local Register Allocator (LRA).  LRA is
  focused to replace GCC reload pass.  The branch is maintained by
  Vladimir Makarov
  &lt; <a href="mailto:vmakarov@redhat.com">vmakarov@redhat.com</a>&gt;
  and will be merged with mainline from time to time.  Patches will be
  marked with the tag <code>[lra]</code> in the subject line.</dd>

  <dt><a href="https://gcc.gnu.org/wiki/LinkTimeOptimization">lto</a></dt>
  <dd>This branch implemented link-time optimization.</dd>

  <dt>lto-pressure</dt>
  <dd>This branch is for work on adding analysis to inlining (for LTO in
  particular) so that it can avoid inlining things that cause excessive
  increases in register pressure.  The branch is maintained by Aaron Sawdey
  &lt;<a href="mailto:acsawdey@linux.vnet.ibm.com">acsawdey@linux.vnet.ibm.com</a>&gt;.</dd>

  <dt>lto-streamer</dt>
  <dd>This was a sub-branch of the lto branch.  It was intended for unstable
  work related to the conversion from DWARF encoding to GIMPLE streamer.
  It is no longer maintained.</dd>

  <dt><a href="https://gcc.gnu.org/wiki/LightweightIpo">lw-ipo</a></dt>
  <dd>This branch aims to implement lightweight IPO.  Patches
  and discussion on this branch should be marked with the tag
  <code>[lipo]</code> in the subject line. The branch is maintained by
  <a href="mailto:davidxl@google.com">David Li</a>.</dd>

  <dt>incremental-compiler</dt>
  <dd>This branch contains change to turn GCC into an incremental
  compiler.  The branch is maintained by Tom
  Tromey <a href="mailto:tromey@redhat.com">tromey@redhat.com</a>.
  Patches for this branch should be marked with the
  tag <code>[incremental]</code> in the subject line.
  </dd>

  <dt>melt-branch</dt>
  <dd>This branch is for
  a <a href="https://gcc.gnu.org/wiki/MiddleEndLispTranslator">Middle End Lisp
  Translator</a> branch, including both the plugin Lisp-like facility
  and static analyzers developed with it. This branch is maintained
  by Basile
  Starynkevitch <a href="mailto:basile@starynkevitch.net">basile@starynkevitch.net</a>. Use
  the <code>[MELT]</code> tag for patches.</dd>

  <dt>mem-ref</dt>
  <dd>This branch is for lowering the GIMPLE IL for memory accesses to
  a flat representation.  See the GCC
  <a href="https://gcc.gnu.org/wiki/MemRef">wiki</a> for a more detailed
  project description.  The branch is maintained by Richard Biener.
  Patches should be marked with the tag <code>[mem-ref]</code> in the
  subject line.</dd>

  <dt>mem-ssa</dt>
  <dd>This branch contains the implementation of Memory SSA, a new
  mechanism for representing memory operations in SSA form (<a
  href="https://gcc.gnu.org/ml/gcc/2006-02/msg00620.html">https://gcc.gnu.org/ml/gcc/2006-02/msg00620.html</a>).
  The branch was maintained by Diego Novillo.  It is no longer
  maintained.</dd>

  <dt>milepost-branch</dt>
  <dd>This branch is for GCC developments done in the Milepost project.
  The branch is maintained by Mircea Namolaru 
  <a href="mailto:namolaru@il.ibm.com">namolaru@il.ibm.com</a>.
  Patches should be marked with the tag <code>[mpost]</code> in the 
  subject line.</dd>

  <dt><a href="https://gcc.gnu.org/wiki/MIRO">miro-branch</a></dt>
  <dd>The purpose of this branch is to develop an improved Mudflap
  with referent objects.  The code of this branch has not been merged
  in trunk.</dd>

  <dt>mpx</dt>
  <dd>The goal of this branch is to support Intel MPX technology.
  The branch is maintained by
  Ilya Enkovich &lt;<a href="mailto:ilya.enkovich@intel.com">ilya.enkovich@intel.com</a>&gt;
  Patches should be marked with the tag <code>[MPX]</code> in the subject
  line.</dd>

  <dt>named-addr-4_3-branch</dt>
  <dd>The goal of this branch was to backport the changes from the
  named-addr-spaces-branch to a GCC 4.3 tree.  This branch was maintained by
  Michael Meissner.  This branch was merged from gcc-4_3-branch.</dd>

  <dt>new-regalloc-branch</dt>
  <dd>Daniel Berlin and Michael Matz were working on an implementation
  of a graph-coloring register allocator on this branch. It is known to
  bootstrap under x86-linux-gnu and ppc-linux-gnu.  It is no longer
  maintained.</dd>

  <dt>no-undefined-overflow</dt>
  <dd>This branch is for tracking overflow behavior on expressions
  rather than on types.
  Patches should be marked with the tag <code>[no-undefined-overflow]</code>
  in the subject line.  The branch is maintained by Richard Biener.</dd>
 
  <dt>objc-improvements-branch</dt>
  <dd>This branch was originally used to merge Objective-C bug fixes and
  enhancements from Apple Computer into the FSF tree; this has now been
  completed.  A later purpose of the branch was to implement the
  Objective-C++ language in the FSF GCC source tree. The message thread
  starting <a href="https://gcc.gnu.org/ml/gcc/2003-07/msg00535.html">here</a>
  describes this at more length.  This branch was being maintained by Zem
  Laski
  &lt;<a href="mailto:zlaski@apple.com">zlaski@apple.com</a>&gt;.  It
  is no longer maintained.</dd>

  <dt>opt-diary</dt>
  <dd>This branch contains the implementation of Optimization Diary, 
  a collection of useful log information generated by the optimizers. 
  This branch was maintained by Devang Patel.  It is no longer
  maintained.</dd>

  <dt>plugin</dt>
  <dd>This branch contains work for a plugin infrastructure in GCC
  to enable additional checking work. This branch is maintained
  by Eric Christopher <a href="mailto:echristo@gmail.com">
  echristo@gmail.com</a> and will be merged with mainline from time to
  time.  Patches will be marked with the tag <code>[plugin]</code>
  in the subject line.</dd>

  <dt><a href="https://gcc.gnu.org/wiki/plugins">plugins</a></dt>
  <dd>This branch adds plugin functionality to GCC.  See the <a
  href="https://gcc.gnu.org/wiki/plugins">plugins wiki page</a> for
  details.</dd>

  <dt>pointer_plus</dt>
  <dd>This branch is for the development of POINTER_PLUS_EXPR.  Which
  is to be used instead of casting between an integer type and a pointer
  type before doing pointer addition.  This branch is being maintained
  by Andrew Pinski.  Patches for this branch should be marked with 
  the tag <code>[PTR-PLUS]</code> in the subject line, and CC'ed to
  <a href="mailto:pinskia@gmail.com">Andrew Pinski</a>.</dd>

  <dt>pph</dt>
  <dd>This branch implements <a href="https://gcc.gnu.org/wiki/pph"> Pre-Parsed
  Headers for C++</a>.  It is maintained by <a
  href="mailto:dnovillo@google.com">Diego Novillo</a> and <a
  href="mailto:crowl@google.com">Lawrence Crowl</a>.  Patches should be
  prefixed with <code>[pph]</code> in the subject line.</dd>

  <dt>pth-icm</dt>
  <dd>This is a sub-branch of the <code>pph</code> branch.  It
  implements
  <a href="https://gcc.gnu.org/wiki/pph#Pre-Tokenized_Headers_.28PTH.29">
  Pre-Tokenized Headers for C++</a>.  Additionally, it contains
  instrumentation code in the C++ parser that was used in an
  incremental compiler model (icm) to study the effects of an
  incremental compiler cache for a compiler server. The branch is
  maintained by <a href="mailto:dnovillo@google.com">Diego Novillo</a>
  and <a href="mailto:crowl@google.com">Lawrence Crowl</a>.  Patches
  should be prefixed with <code>[pph]</code> in the subject line.</dd>

  <dt>ra-improvements</dt>
  <dd>This branch aims to implement several improvements to the
  current register allocator.  Examples include implementing a
  lower-triangular conflict matrix and register coalescing.
  It is hoped that these improvements will not only help the
  current allocator, but will be useful to the other register
  allocation projects such as RABLE and YARA. This branch will
  be merged with the dataflow-branch from time to time.
  The patches for this branch should be marked with the tag
  <code>[ra-improvements]</code> in the subject line.  The branch
  is maintained by <a href="mailto:bergner@vnet.ibm.com">Peter
  Bergner</a>.</dd>

  <dt>redhat/gcc-3_3-branch</dt>
  <dd>This branch used to hold Red Hat GNU/Linux compilers based on
  GCC 3.3.x.</dd>

  <dt>reload-branch</dt>
  <dd>This branch contains a version of reload in which the tracking
  of reload register lifetimes and the inheritance code has been
  rewritten in an attempt to make it more maintainable.  It is no
  longer maintained.</dd>

  <dt>rtl-fud-branch</dt>
  <dd>This branch is for the development of factored use-def chains
  as an SSA form for RTL. Patches should be marked with the tag
  <code>[rtl-fud]</code> in the subject line.  The branch is maintained
  by Steven Bosscher and Kenneth Zadeck.</dd>

  <dt><a href="projects/cfg.html">rtlopt-branch</a></dt>
  <dd>This branch was the successor to the cfg-branch, with the exception
  that it was based on GCC pre-3.4.  The purpose of the branch was to develop
  and test infrastructure for CFG based code improving transformations on
  RTL.</dd>

  <dt>scalar-storage-order</dt>
  <dd>This branch hosts the experimental support to specify a reverse
  storage order (byte/word order, aka endianness) for scalar components
  of aggregate types.  The branch is maintained by
  <a href="mailto:ebotcazou@adacore.com">Eric Botcazou</a>
  and will be merged with mainline from time to time.  Patches will be
  marked with the tag <code>[sso]</code> in the subject line.</dd>
  
  <dt>sel-sched-branch</dt>
  <dd>This branch contains the implementation of the selective scheduling
  approach.  The goal of the branch is to provide more aggressive scheduler 
  implementation with support for instruction cloning, register renaming,
  and forward substitution.   The branch is maintained by Andrey
  Belevantsev &lt;<a href="mailto:abel@ispras.ru">abel@ispras.ru</a>&gt; 
  and Maxim Kuvyrkov &lt;<a href="mailto:mkuvyrkov@ispras.ru">
  mkuvyrkov@ispras.ru</a>&gt; and will be regularly merged with mainline.  
  Patches will be marked with the tag <code>[sel-sched]</code> in 
  the subject line.</dd>

  <dt>spu-4_5-branch</dt>
  <dd>The goal of this branch was to do development for the Cell/B.E. processor,
  in particular to support partitioning functions into multiple sections.  This
  branch was created by Michael Meissner and is now maintained by Ulrich Weigand.
  The branch is merged from mainline.</dd>

  <dt>stack</dt>
  <dd>This branch contains a new stack alignment framework to
  automatically align stack for local variables with alignment requirement.
  The branch is maintained by
  H.J. Lu &lt;<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>&gt;.
  Patches should be marked with the tag <code>[stack]</code> in the subject
  line.</dd>

  <dt>struct-reorg-branch</dt>
  <dd>This branch is for the development of structure reorganization
  optimizations, including field reordering, structure splitting for
  trees.  These optimizations are profile information driven.  This is
  a subbranch of tree-profiling.  This branch is being maintained by
  Caroline Tice, Dale Johannesen, Kenneth Zadeck, Stuart Hastings,
  Mostafa Hagog.</dd>

  <dt><a href="projects/sched-treegion.html">sched-treegion-branch</a></dt>
  <dd>This branch was for the development of a treegion-based instruction 
  scheduler.  The branch was maintained by Chad Rosier.  It is no
  longer maintained.</dd>

  <dt>ssaupdate-branch</dt>
  <dd>This branch served to clean up and improve utilities for the SSA
  form updating, as well as for related changes of the SSA form
  representation.  Most of the changes in this branch were never merged.
  Part of them were incorporated in Diego Novillo's SSA updating
  improvement patch.</dd>

  <dt><a href="projects/strees/index.html">stree-branch</a></dt>
  <dd>This branch was for improving compilation speed and reducing memory
  use by representing declarations as small flat data structures whenever
  possible, lazily expanding them into full trees when necessary.  This
  branch was being maintained by Matt Austern, Robert Bowdidge, Geoff
  Keating, and Mike Stump.  Patches were marked with the tag
  <code>[stree]</code> in the subject line.</dd>

  <dt>structure-aliasing-branch</dt>
  <dd>This branch contains improvements to the tree optimizers ability 
  to do pointer-to-structure aliasing analysis and optimization.  
  This involves some significant rework of the way
  our memory information is represented in the tree-ssa form.
  The branch was maintained by Daniel Berlin.  It is no longer
  maintained.</dd>

  <dt><a href="projects/cli.html">st/cli-be</a></dt>
  <dd>The goal of the branch is to develop a back end producing CLI binaries,
  compliant with ECMA-335 specification.
  This branch was originally maintained by Roberto Costa
  &lt;<a href="mailto:robsettantasei@gmail.com">robsettantasei@gmail.com</a>&gt;.
  Since May 2007, the current maintainers are Andrea Ornstein
  &lt;<a href="mailto:andrea.ornstein@st.com">andrea.ornstein@st.com</a>&gt;
  and Erven Rohou
  &lt;<a href="mailto:erven.rohou@st.com">erven.rohou@st.com</a>&gt;.</dd>

  <dt>thread-annotations</dt>
  <dd>This branch contained the implementation of thread safety annotations
  and analysis (<a href="https://gcc.gnu.org/wiki/ThreadSafetyAnnotation">https://gcc.gnu.org/wiki/ThreadSafetyAnnotation</a>).
  It was superseded by the <a href="#annotalysis">annotalysis branch.</a>
  </dd>

  <dt><a href="https://gcc.gnu.org/wiki/TransactionalMemory"
      >transactional-memory</a></dt>
  <dd>This branch is for the development of transactional memory support
  for GCC.  Patches for this branch should be marked <code>[trans-mem]</code>
  in the subject line.  The branch is maintained by Richard Henderson.</dd>

  <dt><a href="projects/tree-profiling.html">tree-profiling-branch</a></dt>
  <dd>This branch was for the development of profiling heuristics
  and profile based optimizations for trees, such as profile driven inline
  heuristics.  Another goal of this branch was to demonstrate that maintaining
  the CFG and profile information over expanding from GIMPLE trees to RTL
  is feasible and can bring considerable performance improvements.
  It is no longer maintained.</dd>

  <dt>tree-ssa-cfg-branch</dt>
  <dd>This branch has been merged into the tree-ssa-20020619-branch.</dd>

  <dt>ubsan</dt>
  <dd>This branch contains the Undefined Behavior Sanitizer (ubsan).  Ubsan is
  an undefined behavior detector for the C family of languages.  The branch is
  maintained by Marek Polacek
  &lt; <a href="mailto:polacek@redhat.com">polacek@redhat.com</a>&gt;
  and will be merged with mainline from time to time.  Patches will be
  marked with the tag <code>[ubsan]</code> in the subject line.</dd>

  <dt>var-mappings-branch</dt>
  <dd>This branch is for improving debug information based on tracking
  multiple variables per computed value.  The branch is maintained by
  Richard Biener and Michael Matz.  Patches should be marked with the
  tag <code>[varmap]</code> in the subject line.</dd>

  <dt>var-template</dt>
  <dd>This branch is for implementation work on 
      <em>variable template for C++</em>.  It was originally
       created by Gabriel Dos Reis.  It is maintained by
      <a href="mailto:jason@gcc.gnu.org">Jason Merrill</a>.</dd>

  <dt>vect256</dt>
  <dd>This branch is for extending vectorizer to 256bit.  The branch is
  maintained by Richard Biener and H.J. Lu.  Patches should be marked
  with the tag
  <code>[vect256]</code> in the subject line.</dd>

  <dt>yara-branch</dt>
  <dd>This branch contains Yet Another Register Allocator (YARA).
  The branch was maintained by Vladimir Makarov &lt;
  <a href="mailto:vmakarov@redhat.com">vmakarov@redhat.com</a>&gt;.
  It is no longer maintained; some of the work was used as a basis
  for the work on the ira branch.</dd>

  <dt>x32</dt>
  <dd>This branch was to implement
  <a href="https://sites.google.com/site/x32abi/">x32 psABI</a>.
  The branch is maintained by H.J. Lu.  Patches should be marked with the
  tag <code>[x32]</code> in the subject line.</dd>

</dl>

</body>
</html>
